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Abstract 

I  present  a  type-theoretic  encoding  of  objects  that  interprets  method  dispatch  by  self-application 
{i.e.9  method  functions  are  applied  to  the  objects  containing  them)  but  still  validates  the  expected 
subtyping  relationships.  The  naive  typing  of  self-application  fails  to  validate  the  expected  subtyping 
relationships  because  it  is  too  permissive  and  allows  application  to  similarly  typed  objects  that  are 
not  self.  This  new  encoding  solves  this  problem  by  constraining  methods  to  be  applied  only  to  self 
using  existential  and  intersection  types.  Using  this  typing,  I  give  a  full  account  of  objects  including 
self  types  and  method  update.  The  typing  constructs  used  in  this  encoding  appear  to  be  quite  rich, 
but  they  may  be  axiomatized  in  a  novel,  restricted  fashion  that  is  metatheoretically  simple. 
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1  Introduction 


Object-oriented  programming  languages  usually  provide  built-in  primitives  for  object-related  com¬ 
puting.  However,  there  is  also  considerable  interest  in  explaining  such  object  primitives  in  terms  of 
type-theoretic  constructs.  Type-theoretic  accounts  of  object  systems  are  interesting  for  two  main 
reasons:  First,  they  provide  a  flexible  framework  in  which  to  analyze  object-oriented  features  and 
to  explore  combining  them  with  other  powerful  programming  features.  Second,  a  type-preserving 
compiler  must  implement  object  features  in  terms  of  more  basic,  typed  primitives.  To  satisfy  both 
these  needs,  a  type-theoretic  object  encoding  must  be  faithful  to  the  intended  semantics  (static  and 
dynamic)  of  the  object  system,  and  must  also  be  computationally  efficient. 

The  self-application  semantics  [17]  provides  the  most  natural  explanation  of  the  operational  be¬ 
havior  of  objects  whose  methods  have  access  to  self.  In  the  self-application  semantics,  method 
invocation  is  performed  by  extracting  the  desired  method  from  an  object  and  then  applying  that 
method  to  the  entire  object  as  well  as  the  method’s  arguments.  Unfortunately,  the  naive  typing  of 
the  self-application  semantics  does  not  justify  the  desired  typing  rules  for  objects;  in  particular,  it 
blocks  the  expected  subtyping  relationship  that  objects  with  more  methods  may  be  used  in  place 
of  objects  with  less. 

This  difficulty  with  self  application  has  led  to  several  different  proposals  for  type-theoretic  encodings 
of  objects.  Recursive  record  interpretations  [9,  11,  8]  perform  applications  to  self  at  the  time  objects 
are  constructed,  instead  of  at  method  invocation,  resulting  in  records  of  methods  where  self  is 
hardcoded.  In  existential  interpretations  [6,  22,  16],  the  self  argument  provides  some  hidden  state 
of  an  object,  but  no  access  to  methods;  access  to  self  methods  is  again  settled  before  before  object 
construction.  Although  each  of  these  proposals  supports  basic  functionality  for  object-oriented 
programming,  none  provide  the  full  flexibility  of  the  self-application  semantics.  For  example,  none 
allow  methods  to  be  updated  once  objects  have  been  constructed. 

To  solve  this  problem,  Abadi,  Cardelli  and  Viswanathan  devised  an  alternative  interpretation  [3], 
which  retains  the  expressiveness  of  the  self-application  semantics.  Their  interpretation  views  objects 
as  records  containing  methods  and  a  self  field.  The  type  of  the  self  field  is  hidden,  as  in  the 
existential  interpretations,  but  is  constrained  to  be  a  subtype  of  the  full  object’s  type.  When 
objects  are  constructed,  the  self  field  is  filled  with  a  pointer  to  the  object,  and  the  pointer  in  that 
field  is  supplied  to  methods  at  method  invocation,  providing  the  essence  of  self- application. 

Abadi  et  al ’s  device  provides  a  satisfactory  model  of  objects  in  type  theory.  In  particular,  it  justifies 
all  the  desired  typing  rules  for  objects  and  still  allows  the  flexibility  of  the  self-application  semantics 
(such  as  method  update).  However,  as  an  object  encoding  for  use  in  a  practical  compiler,  it  results 
in  some  undesirable  inefficiencies.  As  noted  above,  when  invoking  a  method,  the  self  argument  is 
satisfied  not  by  the  object  itself,  but  by  the  contents  of  a  self  field  of  the  object.  This  means  that 
a  pointer  to  self  must  be  stored  in  every  object,  which  costs  space,  and  that  the  pointer  must  be 
extracted  whenever  methods  are  invoked,  which  costs  time. 


Recovering  Self-Application  Operationally  speaking,  these  overheads  are  easily  avoided  by 
adopting  the  self-application  semantics,  and  have  been  in  untyped  object  systems.  In  a  typed 
setting,  the  difficulty  has  been  in  assigning  types  to  objects  in  a  manner  that  makes  possible  the 
desired  operations  of  an  object  calculus,  particularly  subtyping.  In  this  paper  I  show  that  objects 
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interpreted  by  self- application  can  be  expressed  in  type  theory  without  any  additional  overhead. 
The  paramount  concern  is  that  the  operational  behavior  of  objects  be  undisturbed  in  any  way  by 
the  typing  machinery  that  is  wrapped  around  it. 

A  secondary  contribution  of  the  paper  is  a  careful  analysis  of  the  operational  issues  that  make 
the  various  typing  mechanisms  necessary.  For  example,  I  show  that  the  naive  typing  of  the  self¬ 
application  semantics  does  not  work  because  it  is  too  permissive,  and  fails  to  adequately  state  the 
operational  behavior  of  objects.  In  particular,  it  allows  methods  to  be  applied,  not  only  to  self 
(and  self-application  dictates),  but  to  any  object  of  the  same  type.  However,  that  type  may  be 
a  supertype  of  the  object’s  original  type,  and  therefore  may  be  missing  methods  present  in  the 
original  type.  This  means  that  methods  cannot  count  on  being  supplied  with  all  the  methods  they 
expect,  even  though  those  methods  are  present  in  the  object  itself. 

The  solution  arises  by  devising  a  type  that  does  express  the  operational  behavior  of  objects,  by 
restricting  the  type  so  that  methods  are  applied  only  to  self.  This  is  done  using  an  existential  type 
to  abstract  the  type  of  self,  and  an  intersection  type  to  show  that  the  object  is  both  self  and  a 
collection  of  methods  operating  on  self.  More  generally,  the  methodology  is  to  use  types  to  precisely 
specify  the  allowable  interfaces  to  objects;  in  several  circumstances  problems  will  be  seen  to  arise 
if  types  are  assigned  too  loosely. 

The  ambient  type  theory  required  for  this  encoding  appears  at  first  to  be  very  rich,  but  I  show 
that  little  of  that  expressiveness  is  required,  and  that  the  encoding  may  be  performed  in  a  simple 
and  quite  tractable  type  theory.  At  its  core,  neither  bounded  quantification  nor  higher-order  type 
constructors  are  necessary  (although  there  are  good  reasons  to  add  both).  The  intersection  type 
used  is  also  restricted  enough  to  admit  a  simple  metatheory. 


Overview  The  paper  is  organized  as  follows:  Section  2  develops  the  basic  ideas  of  the  object 
encoding  and  presents  the  type  theory  that  serves  as  the  target  of  the  encoding.  Section  3  extends 
the  encoding  to  support  self  types  and  method  update.  Section  4  compares  the  encoding  in  detail 
with  other  type-theoretic  object  encodings.  Concluding  remarks  appear  in  Section  5. 

In  the  interest  of  brevity,  this  paper  assumes  basic  familiarity  with  the  Girard- Reynolds  polymorphic 
lambda  calculus  [14,  23],  with  subtyping,  with  recursive  types,  and  with  existential  types  for  data 
abstraction  [18].  Some  familiarity  with  the  other  object  encodings  discussed  above  will  also  be 
helpful,  but  is  not  required. 


2  Basic  Developments 


We  begin  by  examining  what  makes  the  naive  typing  for  self- application  fail.  By  way  of  example, 
consider  the  object  types  Point  and  ColorPoint  shown  below. 

Point  =f  {]  getx  :  int  [} 

ColorPoint  =f  {|  getx  :  int,  getc  :  color  [} 

Since  ColorPoint  has  all  the  methods  of  Point,  we  desire  that  ColorPoint  be  a  subtype  of  Point. 
Unfortunately,  this  will  not  prove  to  be  the  case  with  the  naive  typing  for  self-application.  In  the 
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naive  typing,  each  object  is  encoded  as  a  recursive  record  in  which  each  method  takes  an  entire 
object  as  an  argument: 


Point 

ColorPoint 


—  fia.{ getx  :  a  — >  int} 

=  {getx  :  Point  ->  int) 

=  /ia.{ getx  :  a  int,  getc  :  a  — >  color} 

=  {getx  :  ColorPoint  int,  getc  :  ColorPoint  — >  color} 


(naive) 


Suppose  cpt  is  a  ColorPoint.  In  order  for  cpt  to  be  a  member  of  Point,  the  getx  field  of  cpt 
must  be  typeable  as  Point int.  This  is  not  the  case;  the  getx  field  of  cpt  requires  its  argument 
be  a  ColorPoint,  not  just  a  Point.  Consequently,  ColorPoint  is  not  a  subtype  of  Point  using  the 
naive  typing. 


However,  in  the  self-application  semantics,  the  argument  to  the  getx  field  is  not  just  any  object 
of  type  Point.  The  argument  will  always  be  the  object  cpt  itself,  which  is  not  just  a  Point  but 
is  also  a  ColorPoint,  as  desired!  Therefore,  the  intended  subtyping  should  work  out  so  long  as 
an  object’s  methods  are  always  applied  to  the  object  itself,  as  promised  by  self- application.  The 
problem  with  the  naive  typing  is  that  it  is  too  permissive;  it  allows  applying  methods  to  objects 
that  are  not  self.  In  other  words,  the  promise  of  self- application  is  broken  by  the  naive  typing. 

What  we  need,  then,  is  a  typing  mechanism  that  can  require  methods  to  be  applied  to  a  particular 
object.  This  is  achievable  using  abstraction.  Consider  the  existential  type  3 a.  ax  (a->-r).  This  type 
arises  in  typed  closure  conversion,  where  a  is  the  (unknown)  type  of  the  environment,  and  a— >  r  is 
the  type  of  code.  Since  the  type  a  is  unknown,  nothing  can  be  done  with  the  environment  except 
pass  it  to  the  code,  and  likewise  the  code  cannot  be  called  without  presenting  the  environment  as 
an  argument.1  This  is  a  general  mechanism;  we  may  require  that  a  function  be  called  only  with 
a  specific  argument  simply  by  abstracting  the  type  of  the  argument  and  packaging  it  with  the 
function. 


In  order  to  ensure  methods  are  called  with  the  appropriate  argument,  we  abstract  the  type  of  the 
argument  and  package  it  with  the  record  of  methods.  But  for  self- application,  the  argument  and 
the  collection  of  methods  are  one  and  the  same.  Thus  we  package  them  using  an  intersection  type 
to  indicate  that  the  same  object  is  both  the  argument  and  the  record  of  methods: 

Point  =  3a.  a  A  {getx  :  a  — >  int} 

ColorPoint  =  3a.  a  A  {getx  :  a  — >  int,  getc  :  a  — >  color} 

Informally,  a  term  is  a  member  of  the  intersection  type  rx  A  r2  if  it  a  member  of  both  rx  and  r2. 
For  this  encoding  it  is  easily  shown  that  ColorPoint  is  a  subtype  of  Point,  as  desired.  To  invoke 
a  method,  we  just  unpack  the  existential,  extract  the  desired  method  and  apply  it  to  the  object. 
For  example,  let  the  invocation  of  method  t  from  object  o  be  denoted  by  o  <  i  and  suppose  o  is  a 
Point; then 

o  <1  getx  =f  unpack  [a,  x]  =  o  in  (a:. getx)  x 

where  r.i  denotes  the  extraction  of  field  l  from  record  r.  Note  that  o  <3  getx  has  type  int,  as  desired. 
More  generally,  suppose  O  is  {|  tx  :  n, . . . ,  £n  :  rn  |}.  Then  O  is  interpreted  as: 

O  =*  3a.  a  A  {i\  :  a  — >  T\ , . . . ,  tn  :  a  — >  rn} 

1  Throughout  this  paper,  I  assume  call-by- value  evaluation;  therefore  the  argument  cannot  be  spoofed  with  a 
nonterminating  expression  of  type  a. 
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I  will  refer  to  this  encoding  as  the  OEI  encoding,  for  “objects  using  existential  and  intersection 
types,”  following  the  terminology  of  Bruce  et  al.  [7].  In  the  remainder  of  this  paper,  I  will  explore 
the  expressiveness  of  this  encoding  by  showing  how  it  deals  with  various  issues  in  object-oriented 
programming.  The  OEI  encoding  will  not  prove  to  be  sufficient  to  support  self  types  or  method 
update,  but  in  Section  3  I  will  introduce  a  similar  encoding  (called  OREI)  that  is. 


2.1  Object  Construction 

Let  O*  be  the  naive  encoding  for  the  object  type  O: 

O*  =  [icx.{£ i  :  a  — 1  iq , . . . ,  :  a  — >■  Tra} 

I  will  refer  to  members  of  0*  as  pre-objects.  Suppose  po  is  a  pre-object  of  type  O*.  By  unwinding 
the  recursive  type  in  O*  once,  po  can  also  be  given  the  type  { l\  :  O *  — >  :  O*  — >  rn}. 

Therefore,  po  can  also  be  given  the  intersection  type 

0*A{4  :0*-vn,...,4  :0*->rn} 

and  so  an  object  of  type  O  is  constructed  simply  by  hiding  O*: 

pack  po  as  3a.  oA{4  :  a  — t  Ti, . . . ,  tn  :  a  — l  rn}  hiding  O* 

Moreover,  this  packing  operation  has  no  run-time  effect,  provided  we  assume  the  implementation 
erases  types  at  run  time. 


2.2  A  Simplified  Type  Theory 


In  the  preceding  development  I  have  been  using  quite  a  rich  type  system.  For  example,  intersection 
types  are  a  critical  part  of  my  object  encoding.  On  their  own,  intersection  types  are  fairly  innocuous, 
but  combining  them  with  bounded  quantification  leads  to  serious  difficulties  for  type  checking  and 
semantics  [19,  20].  I  do  not  use  bounded  quantification  in  this  paper,  but  there  are  many  good 
reasons  to  include  it  in  a  practical  object  system. 

For  another  example,  when  packaging  pre-objects  in  Section  2.1,  I  implicitly  made  use  of  a  rule 
stating  that  terms  belonging  to  the  recursive  type  pa.r  also  belong  to  the  once-unrolled  version 
of  that  type  rf/ra.r/a].  This  rule  is  natural  according  to  the  intuitive  semantics  of  the  recursive 
type,  but  it  makes  type  checking  considerably  more  difficult  [4]  and  it  restricts  the  possible  models 
of  the  type  theory  [21].  The  usual  solution  to  this  difficulty  is  to  use  explicit  fold  and  unfold 
operations  between  pa.r  and  rjia.T /a\.  but  this  solution  cannot  be  applied  directly  in  my  setting: 
If  e  has  type  pa.r  then  unfold  e  has  type  r[^a.r/a],  but  neither  e  nor  unfold  e  has  the  required 
type  pot.r  A  r[pa.T/a], 

The  difficulties  resulting  from  the  richness  of  the  type  system  may  lead  the  reader  to  wonder  about 
the  practical  applicability  of  the  OREI  encoding.  Fortunately,  subtyping  is  useful  primarily  as 
a  convenience  for  the  programmer,  and  is  not  vital  in  the  intermediate  languages  of  a  compiler. 
Therefore,  the  target  language  of  my  object  encoding  dispenses  with  subtyping  and  instead  uses 
explicit  retyping  coercions. 
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The  target  language,  called  FCl  is  formalized  in  Appendix  A.  The  novelty  of  Fc  lies  in  its  syntactic 
class  of  coercions.  Coercions  are  separated  out  from  ordinary  terms  because  coercions  are  guar¬ 
anteed  to  have  no  run-time  effect;  they  serve  only  to  change  the  type  of  a  term  from  one  type  to 
another.  When  the  compiler  ultimately  generates  machine  code,  it  may  simply  drop  the  coercions. 
All  the  typing  mechanisms  of  this  paper  are  performed  using  coercions,  and  therefore  it  is  clear 
that  the  operational  behavior  of  objects  is  identical  to  what  it  would  be  in  an  untyped  setting.  In 
particular,  no  efficiency  is  sacrificed  to  achieve  strong  typing. 

In  Fc,  members  of  intersection  types  are  introduced  by  a  pair  of  coercions.  If  the  coercions  C\  and 
c2  coerce  r  to  t\  and  r2,  respectively,  then  the  compound  coercion  (ci,c2)  coerces  r  to  T\  A  r2. 
Thus,  a  member  of  an  intersection  type  is  a  single  term  with  two  different  views.2  The  problem 
with  recursive  types  discussed  above  is  then  handled  by  coercing  a  recursively  typed  term  with 
both  an  identity  coercion  and  an  unfold  coercion. 


3  Further  Developments 

3.1  Self  Types 

An  important  feature  for  an  object  encoding  is  to  support  methods  whose  type  involves  the  “type 
of  self.”  For  example,  the  Point  object  type  from  before  may  be  augmented  with  methods  that 
functionally  set  or  increment  the  point’s  position,  returning  a  new  point: 

def 

Point  =  {]  getx  :  int,  setx  :  int  ->  a,  incx  :  a  |}  as  a 

In  the  above  type,  the  type  variable  a  stands  for  the  type  of  self  (“as  a”  serves  as  the  binding 
occurrence  for  the  self  type  variable).  Thus  the  setx  method  takes  an  integer  and  returns  a  new 
object  of  type  Point. 

When  interpreted  using  the  OEI  encoding,  what  we  desire  is  a  solution  to  the  equation: 

Point  =  3(3.  (3  A  {getx  :  (3  — >  int,  setx  :  (3  — >  int  — >  Point,  incx  :  j3  -»  Point} 

The  solution  is  obtained  in  the  natural  manner,  by  wrapping  an  additional  recursive  type  around 
the  encoding: 

Point  =  iia .  3/3 .  (3  A  {getx  :  (3  int,  setx  :  (3  int  — >  a,  incx  :  j3  — »  a} 


More  generally,  suppose  O  is  {|  £i  :  , . . . ,  £n  :  rn  |}  as  a.  Then  O  is  interpreted  as: 

O  =  Aio.3/3./3A{£1:jS^r1,...,4:iS-4rn} 

Note  that  the  recursive  variable  a  may  appear  free  in  T{.  I  will  refer  to  this  encoding  as  the  OREI 
encoding,  for  “objects  using  recursive,  existential  and  intersection  types.” 

2  Dimock  et  al.  [13]  make  use  of  a  similar  idea  by  defining  intersections  to  contain  pairs,  the  components  of  which 
are  required  to  be  identical  when  types  are  erased. 
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3.2  Method  Update 


If  a  method  is  to  return  a  new  object  of  self  type,  it  must  do  so  by  updating  some  of  the  methods 
(or  by  returning  the  original  object  unchanged).  Some  methods  will  do  this  simply  by  calling  other 
methods;  for  example,  the  incx  method  may  create  a  new  point  by  calling  the  setx  method.  Other 
methods  will  do  so  directly;  for  example,  the  setx  method  is  intended  to  return  a  new  object  with 
an  updated  getx  method. 


We  may  implement  such  a  point  by 

mgetx  :  Point  -¥  int 

msetx  :  Point  — >  int  — >  Point 

mjncx  :  Point  — >  Point 

pt  :  Point 


AorPoint*.  12 

Ao:Point*.  Az:int.  o  ■  getx  t=  (Ao':Point*.  x) 
Ao:Point*.  (o  <l  setx)  (o  <  getx  +  1) 

{|  getx  =  TOgetx,  setx  =  msetx,  incx  =  mincx  |} 


where  {]  l\  =  ci, . .  .,£n  =  en  [}  denotes  object  construction  and  o  •  £ e  denotes  the  updating  of 
object  o  by  replacing  its  i  method  with  e. 


Method  update  is  implemented  simply  by  installing  the  new  method  in  the  appropriate  field: 


m' 


Point*  — >  int  Point*  = 


Ao:Point*.  Aauint.  {getx  =  Ao':Point*.  x, 
setx  =  o.setx 
incx  =  o.incx} 


Note  that  the  function  msetx  takes  and  returns  pre-objects  of  type  Point*,  rather  than  objects. 
The  pre-object  result  can  (and  generally  would)  be  coerced  to  an  object  of  type  Point  as  discussed 
in  Section  2.1.  However,  the  argument  necessarily  must  be  a  pre-object.  Terms  of  object  type  (that 
is,  O  as  opposed  to  O *)  may  not  have  methods  updated.  This  is  clear  from  an  inspection  of  the 
object  type  O,  but  there  is  also  a  simple  operational  reason:  Once  in  object  type,  it  is  impossible 
to  determine  the  object’s  original  width;  any  update  could  drop  methods  on  which  other  methods 
depend. 


Consequently,  the  object  calculus  being  compiled  must  distinguish  between  two  sorts  of  object  type: 
“actual”  object  types  and  pre-object  types.  Pre-objects  may  have  methods  updated  and  objects 
may  not.  However,  pre-objects  must  be  promoted  to  become  objects  before  any  subtyping  may  be 
used. 


3.3  Dedicated  Update  Methods 

Unlike  the  encoding  presented  here,  the  object  encoding  of  Abadi  et  al.  supports  updating  of 
methods,  even  after  subtyping  is  used.  It  is  able  to  do  so  by  adding  dedicated  update  methods  to 
objects.  For  each  ordinary  method  in  an  object,  their  encoding  adds  a  second  “update  method” 
that  serves  only  to  update  its  corresponding  method.  In  essence,  update  methods  make  method 
update  possible  after  subtyping  because  they  can  remember  the  record’s  original  width. 

Update  methods  may  be  used  in  the  OREI  encoding  as  well.  I  show  here  how  they  can  be  written 
in  the  object  calculus  by  hand,  but  the  encoding  could  add  them  automatically  (as  in  Abadi 
et  al.)  as  well.  Let  the  type  of  pre-objects  be  written  !{]^i  :  Ti,...,£n  :  rn  |}  as  a.  Suppose  a 
method  foo  has  type  r,  where  r  does  not  make  use  of  the  self  type  variable.  We  may  make  foo 
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updatable  after  subtyping  by  adding  an  extra  method  updateJfoo  resulting  in  an  object  of  type 
{|  f  oo  :  r,  update _f  oo  :  (a  — >  r)  — >■  a, . . .  [}  as  a.  The  method  update_f  oo  is  implemented  by: 

updatejfoo  =  Ao:PreFooType.  A/:(FooType  — y  r).  o  •  f  oo  / 

where  FooType  =  {|  f  oo  :  r,  update _f  oo  :  (a  r)  — >  a, . . .  |}  as  a 

and  PreFooType  =  !{|  f oo  :  r,  updatejfoo  :  (a  — >  r)  — »  a, . . .  |}  as  a 

This  simple  encoding  will  serve  to  update  many  methods,  but  it  depends  essentially  on  the  fact  that 
r  does  not  use  the  self  type  variable  a.  If  a  appeared  free  in  r,  then  it  would  appear  negatively  in 
the  type  of  the  updatejf oo  method,  and  that  negative  appearance  would  prevent  subtyping  from 
working  properly. 

Operationally,  the  problem  is  that  arguments  to  the  update_foo  method  (themselves  functions) 
that  return  the  self  type  might  create  entirely  new  objects,  instead  of  producing  their  results  using 
their  own  self  arguments.  Those  new  objects  could  then  be  missing  fields  expected  by  other  methods 
of  the  present  object. 

We  can  resolve  this  problem  by  adding  bounded  quantification  to  the  system,  and  using  it  to  require 
that  the  arguments  to  an  update  method  produce  their  results  uniformly ,  that  is,  only  by  using 
their  self  arguments.  Consider  the  type  of  update_foo  in: 

{|  f  oo  :  r,  updatejf  oo  :  (V/Ka.  j3  -»  r[/3/a])  ->■  a, . . .  |}  as  a 

Since  (3  is  abstract,  a  prospective  new  method  (i.e.  an  argument  to  updatejfoo)  cannot  create 
an  object  of  type  (3  from  scratch,  it  must  construct  it  using  its  self  argument  (of  type  (3)  and  the 
operations  on  that  self  argument  available  by  virtue  of  being  a  subtype  of  a.  In  other  words,  the 
new  method  must  produce  self-typed  results  using  only  its  self  argument. 

With  this  type,  subtyping  is  permitted  because  a  appears  only  positively.  (A  similar  device  is  used 
by  Abadi  and  Cardelli  [2].)  Note  that  in  order  to  write  any  interesting  uniform  functions,  the  object 
calculus  must  support  structural  rules  for  method  invocation  [3],  where,  for  example,  if  e  has  type 
(3  <  { |  f  oo  :  a, ...  |}  as  a,  then  e  <  f  oo  has  type  /?,  rather  than  the  looser  type  {|  f  oo  :  a, . . .  |}  as  a.3 


3.4  Formalization 

The  discussion  so  far  gives  an  informal  account  of  the  OREI  object  encoding.  We  make  all  this 
precise  by  defining  a  object  calculus  and  giving  a  type  directed  translation  from  that  object  calculus 
into  the  target  language  Fc . 

The  syntax  for  the  object  calculus  appears  in  Figure  1.  To  review  the  notation,  {|  l{  :  t-T-1-™]  |}asa 
and  !{]  t{  :  |}  as  a  represents  the  types  of  object  and  pre-objects,  respectively.  Pre-object 

types  are  subtypes  of  object  types.  The  term  {|  t{  =  e.h=1-^]  [}  creates  a  pre-object  (and  therefore 
an  object,  by  subtyping),  the  term  e  <  i  invokes  method  £  of  object  e,  and  e\  •  £  £=  e<i  updates 
method  £  of  pre-object  e\  by  €2.  The  remaining  notation  is  standard. 

3  Alternatively,  we  can  obviate  the  need  for  structural  rules  and  still  write  uniform  update  methods  by  adding 
higher-order  bounded  quantification  and  quantifying  over  type  operators  that  are  pointwise  subtypes  of  the  operator 
corresponding  to  a  [22]. 
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typos  t  ::=  a  |  int  |  {l\  :  rx, . . .  ,£n  :  rn }  |  rx  ->■  r2  |  Vo.r  | 

:  Ti, . . .  ,tn  :  Tn§  as  a  \  :  Ti, . . .  ,£n  :  Tn§  a 

lorms  e  x  \  i  |  {£x  =  ex,  ...,£n  =  en}  |  e.l  \  Xx:r.e  |  exe2  |  Aa.e 

e[r]  |  =  ex,. .  .,4  =  e„  |}  |  e<£  |  ex  -lt=:  e2 

rontoxts  T  ::=  e  |  r[a]  |  r[a:  :  r] 

Figure  1:  Source  Syntax 

Typos  nro  translated  from  the  source  to  target  language  as  discussed  above: 

|  a 

|  int 

H',  :  '  ['=1-nl} 

In  -t  r2 
|Va.r 

|{|  I ,  :  ['=■•••”]  [f-  as  a 

|!{|  ( ,  :  7;['=*-nl  [}  as  a| 

In  1  lie  interest  of  brevity,  we  present  the  static  semantics  of  the  source  language  and  the  translation 
into  the  target  language  simultaneously.  Appendix  B  gives  rules  governing  three  judgements: 

1.  T  hs  r  type  indicates  that  r  is  a  well-formed  source  type  (in  context  T). 

2.  T  hs  e  :  t  e'  indicates  that  source  term  e  has  type  r,  and  that  e'  is  its  translation  into  the 

target  language. 

3.  T  \~s  n  <  t2  ~t-  c  indicates  that  the  source  type  rx  is  a  subtype  of  the  source  type  r2,  and 
that  c  is  a  target  language  coercion  witnessing  that  subtyping. 

The  source  language  judgements  T  \~s  e  :  r  and  T  hs  rx  <  r2  have  the  obvious  meanings,  and  their 
rules  are  obtained  by  dropping  the  ^  e  and  c  suffixes  from  the  translation  rules. 

With  the  translation  formalized,  the  natural  type  correctness  result  is  easy  to  show: 

Proposition  3.1  Let  the  context  encoding  j F|  be  defined  by: 

M  =  e 

|r[«]|  =  |r|[«] 

|r[*:r]j  =  jrj [a;  :  |r|] 

Then: 

1.  IfT  hs  r  type  then  |T|  \-T  |r|  type. 

2.  If  T  I- s  e  :  t  e'  then  |T|  hT  e' :  |r|. 
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=  a 
=  int 

=  {A- :  |n|[i=1  •n]} 

=  |ti|-t|r2| 

=  Vct.lrl 

=  ga.  33.  /3  A  {£t  :  {3  ->  |rtj^=1'"^}  (where  (3  is  not  free  in  Tt) 
=  ga.  {ti  :  {a  ->•  | | [  | {j  ti  :  rjh=1--n]  |}  as  a\ /a])[* 


Source 

-Q  £{  :  Ti  (a)  ^  1-"J|}asa' 

OE 

3(3.  (3  x  {li 

(3^rl{(3f^'M} 

ORE 

pa.  3/3.  f3  x  {li 

ORBE 

fia.  3/3<a.  f3  x  {li 

OREI 

Ha.  3(3.  (3  A  {li 

(3  — >■  TJ(a)Li=a"'”J} 

Figure  2:  Encodings  of  Object  Types 


3.  IfT  \~s  ti  <  r2  ^  c  then  |F|  hT  c  :  \ri\  •=>  |r2|. 

With  a  formalized  operational  semantics,  dynamic  correctness  of  the  translation  can  also  be  shown, 
using  a  straightforward  (and  uninteresting)  simulation  argument. 

In  the  interest  of  simplicity,  the  source  language  does  not  support  bounded  quantification.  As 
we  have  seen,  bounded  quantification  is  not  necessary  for  many  basic  object-oriented  features. 
However,  there  are  many  excellent  reasons  to  support  bounded  quantification.  For  example,  as 
discussed  in  the  previous  section,  bounded  quantification  (in  conjunction  with  structural  rules  or 
higher-order  type  constructors)  makes  it  possible  to  write  dedicated  update  methods  for  methods 
using  self  type.  It  is  not  difficult  to  extend  the  translation  to  support  bounded  quantification  using 
a  variant  of  the  Penn  interpretation  [5,  12]. 


4  Comparisons 


The  OREI  encoding  discussed  in  this  paper  is  closely  related  to  three  other  abstraction-oriented 
object  encodings:  the  OE  encoding  of  Pierce,  Turner  and  Hoffman  [22,  16],  the  ORE  encoding  of 
Bruce  [6],  and  the  ORBE  encoding  of  Abadi,  et  ah  discussed  previously.  Bruce  et  ah  [7]  cast  each 
of  these  encodings  in  a  common  framework,  and  explore  the  interrelations  between  them. 

The  OREI  encoding  and  each  of  the  three  encodings  from  Bruce  et  ah  encode  object  types  in 
ways  that  appear  fairly  similar.  Figure  2  summarizes  the  encodings  of  object,  types.  However, 
these  syntactic  similarities  mask  significant  differences  in  the  operational  behavior  of  the  various 
encodings.  In  this  section,  I  review  the  discussions  from  Bruce  et  ah  and  show  how  OREI  fits  into 
the  picture. 

The  four  abstraction-oriented  object  encodings  can  be  arranged  in  order  of  the  degree  to  which 
they  specify  the  form  that  the  “state”  of  an  object  must  take,  (as  shown  in  Figure  3): 


1.  The  simplest  of  the  four  is  OE,  which  views  an  object  as  a  pair,  consisting  of  a  state  having 
an  arbitrary  type  and  a  collection  of  methods  operating  on  states.  Methods  that  functionally 
update  an  object  do  so  by  returning  a  new  state.  Since  that  new  state  is  only  part  of  the 
complete  object,  the  caller  has  the  responsibility  of  repackaging  it  to  form  a  complete  object 
by  pairing  it  with  its  methods  and  existentially  sealing  the  pair. 
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unspecific  OE  ORE 


ORBE 


specific  OREI 


Figure  3:  Object  Encoding  Relationships 


2.  The  ORE  encoding  is  like  the  OE  encoding,  except  that  it  moves  the  burden  of  repackaging 
the  state  from  the  caller  to  the  method.  Consequently,  method  types  must  mention  the  full 
type  of  the  object,  and  accordingly  objects  are  given  recursive  types.  Despite  this  difference, 
the  type  of  the  state  itself  in  the  ORE  in  still  completely  unspecified,  as  in  the  OE  encoding. 

3.  The  ORBE  encoding  unifies  the  OE  and  ORE  encodings  by  requiring  that  an  object’s  state  be 
an  object  itself,  thereby  eliminating  the  distinction  between  returning  a  state  and  returning  an 
object.  This  requirement  is  imposed  in  the  type  by  using  bounded  quantification  to  indicate 
that  the  type  of  the  state  is  a  subtype  of  the  full  object’s  type. 

4.  The  OREI  encoding  goes  one  step  further  than  the  ORBE  encoding,  specifying  that  the 
object’s  state  is  not  just  any  object,  but  is  the  selfsame  object  itself.  This  makes  OREI  the 
most  specific  of  the  four,  entirely  specifying  the  object’s  state. 

A  shallow  examination  of  the  type  encodings  would  suggest  that  OREI  bears  the  greatest  resem¬ 
blance  to  the  ORE  encoding,  since  they  differ  only  in  the  type  operator  used  to  join  the  methods, 
product  or  intersection.  However,  the  preceding  discussion  reveals  that  the  similarity  is  deceptive; 
operationally  the  two  encodings  are  very  different.  For  example,  object  states  in  ORE  are  entirely 
unspecified,  while  object  states  in  OREI  are  entirely  specified. 

Operationally,  OREI  is  most  similar  to  the  ORBE  encoding.  Certainly  ORBE  is  closest  in  the 
specificity  spectrum,  but  more  importantly,  ORBE  is  closest  in  expressiveness,  such  as  the  ability 
to  support  method  update.  The  principal  difference  between  the  two  is  the  one  discussed  above: 
ORBE’s  type  allows  its  state  to  be  any  object.  Consequently,  even  though  an  object’s  state  will 
be  the  object  itself  in  common  usage  (at  least  in  a  noncoercive  interpretation  of  subtyping),  the 
possibility  that  it  could  be  another  object  makes  it  impossible  to  take  advantage  of  that  fact.  As 
discussed  in  the  introduction,  this  means  that  the  object  must  use  an  extra  word  to  store  the  state 
pointer,  and  for  every  method  invocation  must  perform  and  extra  dereference  to  obtain  that  state 
pointer. 


4.1  Closure  Conversion 

A  variant  of  the  Abadi,  et  al.  encoding  proposed  by  Viswanathan  [24,  2]  hearkens  back  to  the 
recursive  record  encodings  [9,  11,  8]  by  hiding  the  state  within  method  functions,  but  uses  dedicated 
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update  methods  to  support  method  udpate.  At  high-level  phases  of  a  compiler,  the  recursive 
record  encodings  and  Viswanathan’s  encoding  appear  to  eliminate  the  extra  state  pointer,  but  a 
consideration  of  function  closures  reveals  that  this  is  not  so. 

A  function  having  free  variables  is  implemented  by  transforming  it  into  a  closure,  which  is  a  pair 
the  first  component  of  which  is  an  environment  containing  the  function’s  free  variables,  and  the 
second  component  of  which  is  the  function’s  code  (abstracted  over  the  environment).  Hiding  the 
extra  state  pointer  with  a  method  function  merely  places  it  within  the  environment,  where  it  still 
uses  an  word  and  an  extra  dereference  is  still  required  to  obtain  it. 

Moreover,  an  obvious  optimization  to  perform  after  closure  conversion  is  to  merge  methods’  envi¬ 
ronments  into  the  object,  thereby  eliminating  an  extra  level  of  indirection.  By  appending  methods’ 
free  variables  to  the  end  of  an  object,  we  can  (in  most  cases)  eliminate  the  need  to  allocate  closures 
for  methods.  The  extra  fields  can  then  be  forgotten  using  subtyping.  With  such  an  optimization 
in  play,  the  extra  state  pointer  previously  hidden  within  the  function  now  appears  in  the  object 
again. 


4.2  Full  Abstraction 

The  main  purpose  to  Viswanathan’s  encoding  is  as  a  step  on  the  way  to  a  fully  abstract  object 
encoding,  a  property  not  enjoyed  by  ORBE.  Full  abstraction  in  compilation  is  not  only  of  theoretical 
interest;  in  systems  where  programmers  may  write  code  in  lower-level  intermediate  languages, 
it  is  desirable  that  abstraction  properties  in  the  source  language  be  protected  in  the  lower-level 
intermediate  languages  as  well  [1].  An  interesting  question,  then,  is  whether  the  OREI  encoding  is 
fully  abstract. 

A  formal  proof  is  left  as  future  work,  but  we  may  conjecture  that  OREI  is  fully  abstract  for 
the  object  calculus  without  pre-objects,  but  not  with  pre-objects.  This  is  based  on  the  following 
observations:  We  expect  that  the  encoding  will  be  fully  abstract  if  no  “useful”  operations  can  be 
performed  on  encoded  terms,  that  cannot  be  performed  on  the  original  terms. 


•  The  action  of  the  encoding  on  integers,  records  and  functions  is  trivial,  so  clearly  no  additional 
actions  are  made  possible  in  those  cases.  The  interesting  cases  are  objects  and  pre-objects. 

•  The  sole  operation  available  on  objects  is  method  invocation.  We  wish  to  argue  that  nothing 
can  be  done  with  an  encoded  object  but  invoke  methods.  An  encoded  object  provides  two 
things  (actually,  one  thing  viewable  two  ways):  a  member  of  an  abstract  type  /?,  and  a 
collection  of  functions  with  domain  f3 .  A  member  of  abstract  type  by  itself  is  useless.  The 
functions,  on  the  other  hand,  can  be  called,  but  only  by  providing  a  member  of  (3  as  an 
argument.  The  object  itself  is  the  only  available  member  of  /?,  and  that  function  call  is 
precisely  what  is  meant  by  method  invocation. 

•  The  operations  available  on  pre-objects  are  method  update  and  method  invocation.  However, 
in  an  encoded  object,  the  method  functions  can  be  extracted,  and  from  there  many  things 
are  possible.  Therefore,  for  the  encoding  to  be  fully  abstract,  it  must  be  possible  to  extract 
a  method  function  from  an  unencoded  pre-objects.  Following  Viswanathan  [24],  we  can  very 
nearly  create  a  function  with  identical  behavior  to  a  method  function.  That  function  takes 
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a  new  pre-object  argument,  updates  all  the  methods  of  the  old  pre-object  with  the  new 
pre-object’s  methods,  then  invokes  the  method  in  question  and  returns  its  result. 

out(o  •  £)  =f  Xx.  ((o  •  t\  out(x  *  £x))  •  £2  out(x  •  £2)  *  *  *)  <£ 

The  problem  is  whether  to  update  the  method  being  extracted.  If  it  is  not  updated,  the 
object  created  within  out  does  not  have  quite  the  right  behavior.  If  it  is  updated,  then  the 
field  of  interest  is  obliterated. 

It  appears  that  this  problem  could  be  solved  using  the  same  device  as  Viswanathan  [24],  to 
alter  the  type  of  pre-objects  so  that  methods  cannot  depend  on  their  own  field.  With  such 
a  change,  the  function  out  works  as  intended,  and  the  modified  encoding  appears  to  be  fully 
abstract. 


It  is  worth  pointing  out  that,  although  pre-objects  provide  additional  functionality  over  the  object 
calculus  used  by  Viswanathan  (i.e.,  non-uniform  method  update),  the  (conjectured)  full  abstraction 
of  OREI  minus  pre-objects  is  not  a  comparable  result  to  Viswanathan ’s  because  of  a  difference  in  the 
treatment  of  method  update  in  the  source  calculi.  In  the  OREI  object  calculus,  dedicated  update 
methods  are  just  ordinary  methods  written  to  perform  method  update;  such  fields  can  be  filled 
with  other  non-updating  methods  so  long  as  the  types  are  the  same.  In  contrast,  in  Viswanathan ’s 
calculus,  dedicated  update  methods  are  built  in  and  only  do  update,  and  consequently  a  fully 
abstract  encoding  must  ensure  that  such  methods  actually  do  update.  Preventing  spurious  update 
methods  is  the  primary  issue  Viswanathan ’s  encoding  addresses. 


5  Conclusion 


The  OREI  encoding  is  the  first  type-theoretic  object  encoding  to  use  the  efficient  self-application 
semantics  to  explain  objects’  operational  behavior  and  also  to  give  objects  types  that  justify  the 
intended  subtyping  relationships.  The  enabling  observations  are  that  the  typing  of  objects  must 
enforce  that  objects  are  used  only  in  a  self-applicative  manner,  and  that  such  enforcement  may  be 
done  simply,  using  abstraction  and  restricted  intersection  types. 

Unlike  other  object  encodings  that  use  intersection  types  [10,  15],  the  OREI  encoding  makes  no 
use  of  the  usual  subtyping  behavior  of  intersection  types,  that  r  A  r'  <  r  (in  the  Fc  formalism 
that  71*1  :  r  A  rf  =>  r).  What  is  used  by  the  OREI  encoding  is  the  import  of  intersection  types 
for  controlled  information  hiding.  Existential  types  are  used  to  hide  type  information  by  replacing 
the  information  to  be  hidden  by  an  existentially  quantified  type  variable,  but  this  sort  of  hiding  is 
all-or-nothing.  Using  existential  types  alone,  data  can  be  given  an  abstract  view,  but  cannot  be 
given  multiple  abstract  views  without  making  copies.  Intersection  types  allow  greater  control  over 
information  hiding  by  making  it  possible  for  data  to  be  given  multiple  different  views  simultaneously. 
In  other  words,  intersection  types  allow  data  to  be  placed  in  the  intersection  of  two  views.  This 
application  need  not  have  anything  to  do  with  subtyping. 

Although  the  axiomatization  of  Fc  allows  the  intersection  type  to  enjoy  a  considerably  simpler 
metatheory,  one  should  not  conclude  that  Fc’s  intersection  type  is  the  same  as  a  product  type. 
One  can  give  Fc  a  semantics  in  which  coercions  are  ordinary  functions,  and  in  such  a  semantics  the 
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intersection  and  product  types  are  indeed  the  same.  However,  the  preferred  semantics  is  a  type- 
erasure  operational  semantics  in  which  coercions  are  merely  retyping  operators  with  no  run-time 
effect  whatsoever.  In  that  semantics,  intersection  and  product  types  are  clearly  different.  Moreover, 
it  is  in  that  semantics  that  the  efficiency  goals  of  this  work  are  realized.  Fortunately,  it  is  also  that 
semantics  that  is  most  easily  implemented  by  a  compiler. 
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A  The  Coercion  Calculus 


types  r 

terms  e 

coercions  c 


a  |  int  |  {4  :  ri, . .  .,4  :  t-„}  |  ri  ->■  r2  |  Va.r  |  3 a.r  \ 

[J,a.T  |  Tl  A  72 

x  |  i  |  {4  =  ei, . .  .,4  =  en}  |  el  \  A x:r.e  \  e\ei  \ 
Aa.e  |  unpack  [a,  x\  —  t\  in  e2  |  ce 

id[r ]  |  ci  o  c2  |  {4  :  ci, . .  .,4  :  cn }  |  ci  ->•  c2  |  Va.c  | 
3a.c  |  pa.c  \  apply  T\  in  Va.r2  |  hide  T\  in  3a. r2  | 
fold[pa.T ]  |  unfold[pa.r ]  \  (ci,c2)  |  7T,- [rx  A  r2]  | 
dfOp  {4  I  Tl,  •  •  •  j  £ m  •  Tm  |  £mj-i  Tm+ 1 ,  .  .  . ,  4  •  Tn} 

€  I  r[a]  I  r[*  :  r] 


contexts  T 


r  bT  r  type 


prr - 1 -  ia  £  r) 

T  h T  a  type  v  ' 


T  bT  int  type 


r  bT  Tj  type  (for  l  <  i  <  n)  p  bT  r\  type  T  bT  r2  type 
f  h T  {A  :  •••”■]}  type  T  hT  ri  ->•  r2  type 


T[g]  h t  t  type 
T  \~T  Va.r  type 


(a?r) 


r[g]  hT  T  type 
T  bT  3a. r  type 


(a?T) 


T[a]  b T  r  type  /a  ^  F,  a  appears  \  r  bT  rx  type  T  bT  r2  type 
T  bT  ywa.r  type  \only  positively  in  r  J  T  bT  T\  A  r2  type 


r  hT  e  :  r 


r  bT  x  :  r 


(I»  =  r) 


r  b r  i  :  int 


r  hT  g  :  Tj  (for  i  <  i  <  n)  r  hT  e  :  {A  :  r;[’=1~n]} 


r  hT  {£i  =  ei[<=1-Bl}  :  {A  : 


T  bT 


(i  <  i  < 


r[x  :  71 ]  bT  e  :  r2  r  hr  ri  type  r  hT  ei  :  rx  -►  r2  T  hT  e2  :  r2 

Y=  1  J 


f  bT  XxiTi.e  :  TX  r2 


T  bT  eie2  :  r2 


r[a]  b  T  e  :  r 
T  bT  Aa.e  :  Va.r 


(a^r) 


T  hr  c  :  Ti  =»  r2  r  l~T  e  :  ri 
T  hT  ce  :  r2 


rhTc:ri^r2 


T  hT  r  type 
T  bT  ic?[r]  :  t  =$>  t 


r  hr  ci  :  n  ^  r2  T  hT  c2  :  r2  =£>  r3 
T  hT  ci  o  c2  :  ri  =>■  r3 


F  hT  Cj  :  Tj  =>  r/  (for  1  <  i  <  n) 
r  hT  {A  :  Cjti=1  •••”]}  :  {A  :  =►  {A  :  rfi=1^} 


T  hT  Ci  :  t[  =$■  ri  T  h  T  c2  :  r2  =£• 
r  hT  Cl  ->■  c2  :  (ri  ->•  r2)  (r(  ->■  r^) 
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T[a]  hT  c  :  r\  =>  r2 
T  hT  Va.c  :  Va.Ti  Va.r2 


(a  ^  r) 


T[a]  \rT  c  :  T\  =>  r2 
F  bT  3a. c  :  3a. Tj  3a. r2 


(a^r) 


r [a]  hT  c  :  Ti  r2 
T  hT  /ia.c  :  //a.rx  ==>  /xa.r2 


/a  ^  T,  a  appears 
\on\y  positively  in  c 


r  hr  v^.r2  type  T  hT  rx  type 
r  bT  apply  Ti  in  Va.r2  :  Va.r2  r^fri/a] 


T  hT  3a. r2  type  T  \~T  r\  type 
T  hT  hide  T\  in  3 a.r2  :  r2[ri/a]  ^  3a. r2 


T  hT  //a.r  type 

r  1 ~T  fold[pa.r]  :  r[^a.r/a]  =>  /xa.r 


T  hT  poi.r  type 

T  \~T  unfold[jia.T ]  :  //a.r  =>  r[^a.r/a] 


r  hT  ci  :  r  =>  ti  r  hT  c2  :  r  ^  r2 
r  hT  <cx,c2)  :  r  ^  ri  Ar2 


r  hr  n  a  r2  type 
T  hT  7Tt*[ri  A  r2]  :  rx  A  r2  77 


(*  =  1,2) 


r  bT  r,*  type  (for  1  <  i  <  n) 


T  hT  drop  {£{  :  rt- 


2=1...  ml 


A-  :  n 1 


z+1-n]}  :  {A-  :  =►  {*  :  r^=1-^} 


(m  <  n) 


The  rules  of  Fc  do  not  specify  whether  records  are  taken  to  be  ordered  or  unordered.  If  records  are 
to  be  unordered,  we  use  the  same  typing  rules  and  take  records  and  record  types  to  be  syntactically 
identical  to  ones  with  permuted  fields.  All  the  results  of  this  paper  apply  without  modification  in 
either  version  of  Fc.  However,  the  efficiency  advantages  of  the  self-application  semantics  are  likely 
to  be  most  telling  in  the  version  with  ordered  fields.  If  fields  are  unordered,  one  must  either  view 
records  as  association  lists  of  labels  and  data,  or  adopt  a  coercive  interpretation  of  subtyping  [5]. 
In  either  case,  the  efficiency  advantages  of  self- application  will  stand,  but  will  likely  be  dwarfed  by 
the  costs  of  supporting  unordered  fields. 


B  The  Object  Encoding 


Static  Semantics  and  Translation  Rules 


r  r  type 

FreeTypeVariables(r)  C  r 
T  r  type 
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r  \-s  t  type 
rhsr<r^  *d[|r|] 


r  Hs  n  <  7-2  ^  Cl  r  Kg  T2  <  T3  ^  C2 

r  hsn  <  r3  c2  o  cj 


r  h5  ri  <  t2  C 


r  hs  Ti  <  t-  C{  (for  1  <  i  <  n)  T  hs  r,-  type  (for  n  <  i  <m) 

r  hs  {A  :  r^=1~H}  <  {4.  :  ~ 

{A-  :  Ci^1-"]}  o  drop  {A  :  |  A  :  |r.|t’=»+i-H} 


(m  >  ti  ) 


£  h5  <  ti  ^  Ci  rhsr2<r'^  c2 
r  h5  Tj  r2  <  Tj  — >  ^  Ci  — >■  c2 


_ rM^7-x<r2^c _ 

r  Va.ri  <  Va.r2  ^  Va.c  1  *  ; 


Ti  <  t[  ^  (for  1  <  i  <  n)  r[o]  hs  r4-  type  (for  n  <  i  <  m) 

r  fl  A  :  0  as  a  <  fl  A  :  r/[i=1-n]  D  as  a 

pa.  3(3.  id[(3]  A  ({A  :  «c?[/3]  — *•  Cf[,=1-n]}  0 
drop  {A  :  (3  ->  |rt-|I,=1-n]  | 

A  :  /?  — >  |Ti|[i=n+1-H}) 


(a  gT,(3  g  Ti,m>  n, 
a  appears  only 
positively  in  r,- 


r[a]  bs  Ti  type  (for  1  <  i  <  n) 

r  !{|  A  :  rji=1-nl  &  as  a  <  fl  A  :  [}  as  a 

fold[r\  o 

hide  t*  in  3(3.  (3  A  {A  :  (3  ->  |rt|[r/a][i=1-"]}  o 
(*d[r*],  un/oW[r*]) 
where  r  =  |{|  A  :  rj*=1-"^  [}  as  a\ 
and  t*  =  |!{|  A-  :  |}  as  a| 


(«  £  r,  (3  g  n) 


r  \~s  e  :  t  e' 


r  (-s  e  :  T\  e'  r  hg  T\  <  r2  c 
rhse  :r2^ce' 


fArr^i 


(F(*)  =  7") 


r  (-5  i :  int  ^  i 


T  hs  e;  :  Ti  ^  e\  (for  1  <  *  <  n) 
r  hg  {A  =  et-[‘=1— nl}  :  {A  :  {A  -  e'[i=1-n]} 


r  hg  e  :  {A  :  rt-P=1-n1}  e> 

r  l~g  e.ij  :  Tj  e'.A 


(1  <  j  <  n) 
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r[x  :  Tj]  h5  e  :  r2  e'  T  \~s  tx  type  (  w  ^  r  \~s  ex  :  ri  -4  r2  ^  e'j  T  hs  e2  :  r2  ^  e2 

T-  l21  £  1 ) 


T  hs  Xx-.ry.e  :  Ti  ->  r2  Ax:|ri|.e' 


r  h 5  eie2  :  r2  ^  eie2 


rfttl  h  se:rve'  .  ,  T  hs  e  :  Va.r'  ^  e'  T  hs  r  type 

-7  (*  2  r)  - 


T  h5  Aa.e  :  Va.r  ^  Aa.e' 


T  h5  e[r]  :  t'[t/<x]  e'[|r|] 


£M  hs  e,  :  !{|  A'  :  rt*=1-nl  &  as  a  ->  r,-[(fl  l,-  :  &  as  a) /a] 

r  Hs  fl  £i  =  g(-[*=1-n]  &  :  !{|  A-  :  rji=1-n]  |}  as  a  — 

(/oM[|!fl  4-  :  &  as  a|]){*  =  e*'=1"w]} 


(ce  ^  T,  1  <  i  <  n) 


r  Hs  e  :  { 

|£.:r.[<=1...»]  | 

|}  as  a  e* 

T  \-s  e  <  t{ :  Ti\ 

KK-: 

T\i- l...n]  ||  ag  ct) / o;] 

unpack  [/3,  x]  =  unfold[T ]  e'  in  (?r2[r']  x).i  (tti [r']  x) 
where  t'  —  (3  A  :  (3  — >■  |T,i|[r/Q']^-1"-"^} 

and  f  =  |{|  t{ :  ri*=1-n]  |}  as  a| 


r  Hs  d  :  !{]  ti  :  T;[i=1~n]  |}  as  a  e[ 

T  hs  e2  :  !{|  ti  :  r8-[*=1-w]  j}  as  a  ->  rj[({|  l,-  :  r,-[,=1-nj  |}  as  a) /a]  e2 

T  \-s  ex  •  £j  e2  :  !{ |  ti  :  r^=1-nl  |}  as  a 

/et  x  =  «n/oW[|!{]  |}  as  a|]  e'j 

in 

/oW[|!flA-:rf[<=1-wl|}asa|] 

{A  =  x.^=W_1],<?  =  e'2,A-  =  x.^[*'=i+1-n]} 


(1  <  i  <  n,  /3  g  Ti) 


(1  <  j  <  n,x  g  e{) 


18 


School  of  Computer  Science 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 


Carnegie  Mellon  University  does  not  discriminate  and  Carnegie  Mellon  University  is  required 
not  to  discriminate  in  admission,  employment,  or  administration  of  its  programs  or  activities 
on  the  basis  of  race,  color,  national  origin,  sex  or  handicap  in  violation  of  Title  VI  of  the  Civil 
Rights  Act  of  1964,  Title  IX  of  the  Educational  Amendments  of  1972  and  Section  504  of  the 
Rehabilitation  Act  of  1973  or  other  federal,  state,  or  local  laws  or  executive  orders. 

In  addition,  Carnegie  Mellon  University  does  not  discriminate  in  admission,  employment  or 
administration  of  its  programs  on  the  basis  of  religion,  creed,  ancestry,  belief,  age,  veteran 
status,  sexual  orientation  or  in  violation  of  federal,  state,  or  local  laws  or  executive  orders. 
However,  in  the  judgment  of  the  Carnegie  Mellon  Human  Relations  Commission,  the  Depart¬ 
ment  of  Defense  policy  of,  “Don’t  ask,  don’t  tell,  don’t  pursue,”  excludes  openly  gay,  lesbian 
and  bisexual  students  from  receiving  ROTC  scholarships  or  serving  in  the  military.  Neverthe¬ 
less,  all  ROTC  classes  at  Carnegie  Mellon  University  are  available  to  all  students. 

Inquiries  concerning  application  of  these  statements  should  be  directed  to  the  Provost, 
Carnegie  Mellon  University,  5000  Forbes  Avenue,  Pittsburgh,  PA  15213,  telephone  (412)  268- 
6684  or  the  Vice  President  for  Enrollment,  Carnegie  Mellon  University,  5000  Forbes  Avenue, 
Pittsburgh,  PA  15213,  telephone  (412)  268-2056. 

Obtain  general  information  about  Carnegie  Mellon  University  by  calling  (412)  268-2000. 


